Subject: RFC issues/comments after the DLSw V1 Interoperability Test

From: [email-masked] (Allen Goldberg)
Date: Fri, 20 Oct 95 12:17:34 EDT

Below is a list of issues that DLSw V1.0 Interoperability Testers have
come across in the development/test of their V1.0 implementations. Also
included, where applicable, is the tentative consensus that was reached
at the Test. Steve Klein will be leading the discussion on these issues
at AIW9.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

ISSUE:

- Should a non-2067 write port be allowed?

RESOLUTION:

- We should clarify that 2067/2065 is required.

---------------------------------------------------------------------------
ISSUE:

- Capabilities Exchange error handling

RESOLUTION:

- Some vendors were bringing down the transport connection when they did
not like the received capabilities.  This will be changed to send a neg
response, then it's up to the neg response receiver to take it down.  If
this rule isn't clear enough in the  spec we should improve it.

---------------------------------------------------------------------------
ISSUE:

-  Vendor context CV

RESOLUTION:

- Must be present if any vendor-specific capabilities are included.
Vendor ID CV is not to be used for decoding vendor-specific CVs.

---------------------------------------------------------------------------
ISSUE:

- NetBIOS - RII bit in SSP header MAC addresses

RESOLUTION:

Must be 0.

---------------------------------------------------------------------------
ISSUE:

- Fill in of NetBIOS MAC/LLC header

RESOLUTION:

- MAC addresses - should be non-canonical and in source/destination
    order just like the frame that generated the SSP message
- AC/FC - copied from frame if token-ring, zero if not token-ring
- LLC header - copied from frame generating SSP message

Discussion did not reach consensus but proposed as:

- RII bit in SA - copied from LLC frame
- RI ctl field  - if RII set, copied from LLC frame (need to decide
    if length should be bumped up for pad), otherwise zero.  Related
    issue - should we extend lf bits in SSP header to be valid for
    DATAFRAME?
- RI field - original RIF (maybe null) padded with zeros to a total
    length (including RI ctl) of 18 bytes.

---------------------------------------------------------------------------
ISSUE:

- Vendor ID. This number is the IEEE assigned number but some vendors
are having difficulty in obtaining one.

RECOMMENDATION:

- Either use the SMI Network Management Private Enterprise Code assigned
by IANA since it's logical and easier to obtain OR allow a zero vendor
ID for those who don't have a Vendor ID.

---------------------------------------------------------------------------
COMMENTS/QUESTIONS ON THE RFC (I believe these were already posted):

1 - page 27 : 5.2.1. DISCONNECTED State
  In the case of reception of broadcast DLC_XID, the action is to send
  CANUREACH_ex. What will happen when ICANREACH_ex arrives? Do we 
have to  send XIDFRAME to the partner then or was this DLC_XID used 
just to reach  the topology table?

2 - page 27 : 5.2.1. DISCONNECTED State
  In the case of reception of DLC_CONTACTED, don't we have to start
  CS_TIMER as well as for reception of non broadcast DLC_XID?

3 - page 28 : 5.2.2. RESOLVE_PENDING State
  Perhaps XPORT_FAILURE must not be ignored! In this case, a suggestion
  would be to send DLC_HALT_DL and then to change for 
HALT_PENDING_NOACK  state.

4 - page 29 : 5.2.3. CIRCUIT_START State
  In the case of reception of ICANREACH_cs, there is a reference to a note
  that doesn't exist anymore.

5 - page 29 : 5.2.3. CIRCUIT_START State
  In the case of reception of CANUREACH_cs for circuit in opposite
  direction, we may add a DLC_HALT_DL for the circuit which was in
  CIRCUIT_START state.

6 - page 29 : 5.2.3. CIRCUIT_START State
  In the case of CS_TIMER_EXP or XPORT_FAILURE, we may send a 
DLC_HALT_DL and change to HALT_PENDING_NOACK state in order to 
free the circuit.

7 - page 30 : 5.2.4. CIRCUIT_PENDING State
  What happens if REACH_ACK doesn't arrive? Perhaps would it be useful 
to handle a timer in this state like in CIRCUIT_START state.

8 - page 36 : 5.2.10. DISCONNECT_PENDING State
  What happens if DL_HALTED doesn't arrive?  Perhaps would it be useful 
to handle a timer in this state too.

9 - page 39 : 5.3. NetBIOS Datagrams
  Why a NB_Status_Response must be sent to all remote DLSw in order to 
a specific partner?

10 - page 42 : 5.4.1.2. SENT_EX State
  What happens if ICANREACH_ex never arrives? Do we have to handle a 
timer in this state or to accept that a DLC_ERROR arrives to free the
  "circuit"?

11 - page 43 : 5.4.1.3. RECEIVED_EX State
  What happens if DLC_RESOLVED never arrives? Do we have to handle a 
timer in this state or to accept that a DLC_ERROR arrives to free the
  "circuit"?

12 - page 42 : 5.4.2..2. SENT_EX State
  What happens if NETBIOS_NR_ex never arrives? In this case, the only
  solution is to handle a timer...
  The same situation may happen in RECEIVED_EX State if the datagram
  NAME_RECOGNIZED does't arrive as well as in SENT_REC_EX State.

13 - page 39 : 5.4.2.2. SENT_EX State
  Do the words "different local session number" mean "different response
  correlator"? (in NAME_QUERY Frame, no field contains a session number)

14 - page 83 : 8.7.1..6. A frame arrives from sender
  The following sequence is incorrect :
    IF NOT GrantDelayed THEN
      IF GrantedUnits <= CurrentWindow THEN
        IF FCACKOwed THEN
          Protocol Violation
        ELSE
          Repeat Window Operator
        ENDIF
      ENDIF
    ENDIF

  To illustrate the problem, here is the following example (Window = 3):

       Granted Units                               Granted Units
         for Sender                                for Receiver
            0                                           0
            3              <---------FCIND(Rpt)         3
            2              FCACK-------------->         2
            2                       -FCIND(Rpt)         5
            1              DATA-----|--------->         4
            0              DATA-----|--------->         3****
            3              <---------
            2              FCACK-------------->

  **** : at this time GrantedUnits = 3 and is <= CurrentWindow;
         furthermore, FCACKOwed = TRUE, so according to the algorithm,
         there is Protocol Violation : not for the Sender.

  The following algorithm which works like in section 8.7.2.8 may be a
  solution :

    IF NOT GrantDelayed THEN
      IF FCACKOwed THEN
        IF GrantedUnits < CurrentWindow THEN
          Protocol Violation
        ENDIF
      ELSE
        IF GrantedUnits <= CurrentWindow THEN
          Repeat Window Operator
        ENDIF
      ENDIF
    ENDIF

15 - page 88 and 89 : 8.8.3. Example Reset Window Flows
  The last line for the 3 examples seems to be incorrect : for the
  receiver, the window value is still 2 and the GrantedUnits value is 1.